home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 26 / Cream of the Crop 26.iso / program / ddj0897.zip / RCSC.ZIP / PACKAGES / GREP15AX.ZIP / README < prev    next >
Text File  |  1989-11-15  |  8KB  |  153 lines

  1. This README documents GNU e?grep version 1.5.  All bugs reported for
  2. previous versions have been fixed.  I would like to emphasize:  Please
  3. send bug reports directly to me (mike@ai.mit.edu), *not* bug-gnu-utils.
  4.  
  5. Changes needed to the makefile under various perversions of Unix are
  6. described therein.
  7.  
  8. If the type "char" is unsigned on your machine, you will have to fix
  9. the definition of the macro SIGN_EXTEND_CHAR() in regex.c.  A reasonable
  10. definition might be:
  11.     #define SIGN_EXTEND_CHAR(c) ((c)>(char)127?(c)-256:(c))
  12.  
  13. GNU e?grep is provided "as is" with no warranty.  The exact terms
  14. under which you may use and (re)distribute this program are detailed
  15. in a comment at the top of grep.c.
  16.  
  17. GNU e?grep is based on a fast lazy-state deterministic matcher (about
  18. twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
  19. search for a fixed string that eliminates impossible text from being
  20. considered by the full regexp matcher without necessarily having to
  21. look at every character.  The result is typically many times faster
  22. than Unix grep or egrep.  (Regular expressions containing backreferencing
  23. may run more slowly, however.)
  24.  
  25. GNU e?grep attempts, as closely as possible, to understand compatibly
  26. the regexp syntaxes of the Unix programs it replaces.  The following table
  27. details the various special characters understood in both the grep and
  28. egrep incarnations:
  29.  
  30. (grep)    (egrep)        (explanation)
  31.   .       .        matches any single character except newline
  32.   \?       ?        postfix operator; preceeding item is optional
  33.   *       *        postfix operator; preceeding item 0 or more times
  34.   \+       +        postfix operator; preceeding item 1 or more times
  35.   \|       |        infix operator; matches either argument
  36.   ^       ^        matches the empty string at the beginning of a line
  37.   $       $        matches the empty string at the end of a line
  38.   \<       \<        matches the empty string at the beginning of a word
  39.   \>       \>        matches the empty string at the end of a word
  40.  [chars] [chars]    match any character in the given class; if the
  41.             first character after [ is ^, match any character
  42.             not in the given class; a range of characters may
  43.             be specified by <first>-<last>; for example, \W
  44.             (below) is equivalent to the class [^A-Za-z0-9]
  45.  \( \)      ( )        parentheses are used to override operator precedence
  46.  \<1-9>      \<1-9>    \<n> matches a repeat of the text matched earlier
  47.             in the regexp by the subexpression inside the
  48.             nth opening parenthesis
  49.   \       \        any special character may be preceded by a backslash
  50.             to match it literally
  51.  
  52. (the following are for compatibility with GNU Emacs)
  53.   \b       \b        matches the empty string at the edge of a word
  54.   \B       \B        matches the empty string if not at the edge of a word
  55.   \w       \w        matches word-constituent characters (letters & digits)
  56.   \W       \W        matches characters that are not word-constituent
  57.  
  58. Operator precedence is (highest to lowest) ?, *, and +, concatenation,
  59. and finally |.  All other constructs are syntactically identical to
  60. normal characters.  For the truly interested, a comment in dfa.c describes
  61. the exact grammar understood by the parser.
  62.  
  63. GNU e?grep understands the following command line options:
  64.     -A <num>    print <num> lines of context after every matching line
  65.     -B <num>    print <num> lines of context before every matching line
  66.     -C        print 2 lines of context on each side of every match
  67.     -<num>        print <num> lines of context on each side
  68.     -V        print the version number on stderr
  69.     -b        print every match preceded by its byte offset
  70.     -c        print a total count of matching lines only
  71.     -e <expr>    search for <expr>; useful if <expr> begins with -
  72.     -f <file>    take <expr> from the given <file>
  73.     -h        don't display filenames on matches
  74.     -i        ignore case difference when comparing strings
  75.     -l        list files containing matches only
  76.     -n        print each match preceded by its line number
  77.     -s        run silently producing no output except error messages
  78.     -v        print only lines that contain no matches for the <expr>
  79.     -w        print only lines where the match is a complete word
  80.     -x        print only lines where the match is a whole line
  81.  
  82. The options understood by GNU e?grep are meant to be (nearly) compatible
  83. with both the BSD and System V versions of grep and egrep.
  84.  
  85. The following incompatibilities with other versions of grep exist:
  86.     the context-dependent meaning of * is not quite the same (grep only)
  87.     -b prints a byte offset instead of a block offset
  88.     the \{m,n\} construct of System V grep is not implemented
  89.  
  90. GNU e?grep has been thoroughly debugged and tested by several people
  91. over a period of several months; we think it's a reliable beast or we
  92. wouldn't distribute it.  If by some fluke of the universe you discover
  93. a bug, send a detailed description (including options, regular
  94. expressions, and a copy of an input file that can reproduce it) to me,
  95. mike@wheaties.ai.mit.edu.
  96.  
  97. GNU e?grep is brought to you by the efforts of several people:
  98.  
  99.     Mike Haertel wrote the deterministic regexp code and the bulk
  100.     of the program.
  101.  
  102.     James A. Woods is responsible for the hybridized search strategy
  103.     of using Boyer-Moore-Gosper fixed-string search as a filter
  104.     before calling the general regexp matcher.
  105.  
  106.     Arthur David Olson contributed code that finds fixed strings for
  107.     the aforementioned BMG search for a large class of regexps.
  108.  
  109.     Richard Stallman wrote the backtracking regexp matcher that is
  110.     used for \<digit> backreferences, as well as the getopt that
  111.     is provided for 4.2BSD sites.  The backtracking matcher was
  112.     originally written for GNU Emacs.
  113.  
  114.     D. A. Gwyn wrote the C alloca emulation that is provided so
  115.     System V machines can run this program.  (Alloca is used only
  116.     by RMS' backtracking matcher, and then only rarely, so there
  117.     is no loss if your machine doesn't have a "real" alloca.)
  118.  
  119.     Scott Anderson and Henry Spencer designed the regression tests
  120.     used in the "regress" script.
  121.  
  122.     Paul Placeway wrote the manual page, based on this README.
  123.  
  124. If you are interested in improving this program, you may wish to try
  125. any of the following:
  126.  
  127. 1.  Make backreferencing \<digit> faster.  Right now, backreferencing is
  128.     handled by calling the Emacs backtracking matcher to verify the partial
  129.     match.  This is slow; if the DFA routines could handle backreferencing
  130.     themselves a speedup on the order of three to four times might occur
  131.     in those cases where the backtracking matcher is called to verify nearly
  132.     every line.  Also, some portability problems due to the inclusion of the
  133.     emacs matcher would be solved because it could then be eliminated.
  134.     Note that expressions with backreferencing are not true regular
  135.     expressions, and thus are not equivalent to any DFA.  So this is hard.
  136.  
  137. 2.  There is a bug in the backtracking matcher, regex.c, such that the |
  138.     operator is not properly commutative.  Let x and y be arbitrary
  139.     regular expressions, and suppose both x and y have matches at
  140.     some point in the target text.  Then the regexp x|y should select
  141.     the longest of the two matches.  With the backtracking matcher, if the
  142.     first match succeeds it does not even try the second, even though
  143.     the second may be a longer match.  This is obviously of no concern
  144.     for grep, which does not care exactly where or how long a match is,
  145.     so long as it knows it is there.  On the other hand, the backtracking
  146.     matcher is used in GNU AWK, wherein its behavior can only be considered
  147.     a bug.
  148.  
  149. 3.  Handle POSIX style regexps.  I'm not sure if this could be called an
  150.     improvement; some of the things on regexps in the POSIX draft I have
  151.     seen are pretty sickening.  But it would be useful in the interests of
  152.     conforming to the standard.
  153.